Apparatus, methods and systems for anonymous communication

ABSTRACT

Anonymous voice communication between a first station and a second station is facilitated by providing an interface that allows input of a transaction specification from at least one of the first and second stations. A reference code associated with the transaction is generated, there being a defined relationship between the reference code and the address of the second station for voice communication. The reference code is supplied to the first station, and a voice communication request and the reference code are received from the first station. The reference code is used to recover said address and a channel for voice communication is opened between said first and second stations. Voice communication can thereby be established between the first and second stations without providing the address of the second station to the first station.

This reissue application is related to the following co-pending reissueapplications of U.S. Pat. No. 7,099,304 granted on Aug. 29, 2006; Ser.No. 12/199,647 filed on Aug. 27, 2008; Ser. No. 12/199,631 filed on Aug.27, 2008; Ser. No. 12/199,711 filed on Aug. 27, 2008; Ser. No.12/200,014 filed on Aug. 28, 2008; Ser. No. 12/200,148 filed on Aug. 28,2008; and Ser. No. 12/200,305 filed on Aug. 28, 2008.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims benefit of Provisional Application No.60/230,021 filed Sep. 5, 2000, the entire disclosure of which is herebyincorporated by reference herein for all purposes.

BACKGROUND OF THE INVENTION

The Internet is a collection of computer networks from which usersobtain and share information. The Internet has evolved from the ARPAnetto become the largest computer network in the world. The Internetsupports various services. Of these services, the World Wide Web (the“Web”) and email are among the most widely used. Of these, the Webcomprises a collection of hundreds of millions of documents (“Webpages”) written in mark up languages such as HTML, XML, and WML.

In Internet transmissions, Transaction Control Protocol/InternetProtocol (“TCP/IP”) is the communication standard. TCP/IP is a suite ofprotocols enabling communication between each node of the network. Withthe increasing bandwidth being offered by network carriers, not onlydata but also voice, audio and video are increasingly being transmittedthrough the network.

The evolution of the Internet continues and, in so doing, drivesInternet-related product development, including in hardware, softwareand protocols. The Internet is extending in wireless communication andhandheld devices. As an example, Internet-enabled cellular phones (suchas smart and super phones) combine the features of cellular phones withthe ability to access the Internet. As another example, certain personaldigital assistants (“PDAs”) are directed to couple standard featureswith wireless access to the Internet. These phones, PDAs and otherhandheld devices exploit protocols such as, but not limited to, WAP, Webclipping, HDML or CHTML. Through these Internet-enabled devices, it isanticipated that users will not only place phone calls, organize theirschedules and/or otherwise exploit the respective device's standardfunctionality, but also access the Internet for browsing the Web,obtaining information, communicating (e.g., via email) and the like. Inso doing, it is also anticipated that the device's standard features andthe Internet's benefits will both be enhanced.

The evolution of the Internet also implicates an evolution, if notrevolution, in the infrastructure of communication networks. Today,people generally obtain personal access to the Internet by dialing upInternet service providers; the dial up may be carried for example overcircuit-switched networks (“CSN”), typically via localtelecommunications providers. In dial up, CSNs establish a physicalcircuit, which is dedicated exclusively to the call between the parties.

While generally available to users, CSNs appear to be in relativedecline, being increasingly supplanted by packet-switched technologies.Packet-switched technologies significantly increase a network's speedand capacity. In packet-switched networks, traffic is digitized,compressed, and transported as packets. These networks enable thepackets of a particular transmission to travel through various channelsfrom source to destination. Moreover, these networks enable traffic invaried media types, including voice, audio, video, text, data andfacsimile. In enabling the varied types, moreover, the networks maydeploy technologies (e.g., ATM), which enable significant features, suchas quality of service, wherein priorities are assigned to and among themedia types (e.g., so that packets of voice communications arrivetimely, thereby ensuring adequate fidelity for the conversation).

Packet-switched networks follow open standards. Accordingly, thesenetworks enhance the ability of service providers to deploy newservices, including high-bandwidth services for Internet use orotherwise (e.g., television programming and/or video on demand). Bycomparison, in circuit-switched networks, the call control functionalityand the service logic tend to be buried within the switch. Moreover, thefunctionality generally is proprietary to the switch vendors. As such,new services generally are deployed at the discretion of the switchvendor, not the service providers.

In addition to hardware, software, protocols and infrastructure, theevolution of the Internet also implicates development of new andimproved services. Already, marketplaces on the Internet (i.e., virtualmarketplaces) are well known and increasingly diverse in direction,content and business model. Ebay, Yahoo, E*Trade and Amazon areexamples, each facilitating transactions, including the selling, buyingand auctioning of merchandise and the provision of services, with andamong enterprises and individuals. The merchandise and services comprisea wide variety, from books to automobiles, to stocks, to calendaring,that seems ever expanding in breadth.

Overcoming the geographic constraints of physical proximity, theInternet also introduces increasing and new opportunities for people tomeet and interact with each other. Communities on the Internet (i.e.,virtual communities) are well known and increasingly diverse in style,content and target participants. Virtual communities typically offerservices and associated tools, such as chat rooms, email and Webpublishing. Through these services and tools, virtual communities enabletheir participants to communicate, including to express their respectiveviews, share common interest(s) and otherwise interact as if in thephysical world, and increasingly in ways not available in the physicalworld.

Virtual marketplaces may facilitate the exchange or trading of ideas,knowledge and information between and among individuals and entities(sometimes referred to collectively herein as “participants”). Thesevirtual marketplaces (“information marketplaces”) tend to have anexpress or implied premise, understanding or foundation: individuals andentities have one or more interests and/or areas of expertise that canor should be (a) shared with or provided to participants, (b)nurtured/advanced by interaction with participants, and/or (c) otherwisecommunicated to or with other participants for some derived benefit ofeither or both participants.

In an example of a transaction in a contemplated informationmarketplace, a participant (the “initiator”) posts a question, inquiryor view (“posting”) at a selected Web site of the marketplace. Theinitiator has the goal of obtaining one or more of answers, information,direction, responses or interaction (“response”) from or with one ormore participants. The initiator may choose to direct the posting toselected participants (“experts”). The initiator preferably is enabledto select experts based on the experts' identified or claimedinterest/expertise. The initiator may have identified interests andexpertise. Indeed, the initiator may also be an expert in themarketplace and, conversely, the expert may also be an initiator in themarketplace.

A contemplated information marketplace preferably supports provision ofthe qualifications or characteristics of its experts, initiators and/orparticipants and may do so variously. In an example case, themarketplace publishes qualifications/characteristics (e.g., on Web sitesor page(s)). The qualifications/characteristics may be mandated orvoluntary, or a combination. The qualifications/characteristics may,particularly in the case of initiators, be selectable by theparticipant. The qualifications/characteristics may include variousdata, such as, among others, profile descriptions, transaction history(e.g., in the marketplace), ratings (e.g., marketplace, participant,expert and/or initiator provided), comments and reviews (e.g.,marketplace, participant, expert and/or initiator provided), feeschedules or other forms of pricing. Profile descriptions may include,among other things, certifications (e.g., marketplace, professional, orgovernmental), specialties, sub-area(s) of interest/expertise,education, years of practice, awards, geographic location, andgeographic scope or limitation on the interest/expertise. Profiledescriptions may also include—particularly for initiators—qualificationsor characteristics in the field of the posting, transaction history inthe field of the posting, credit rating, age, education level, andgeographic location.

Once an initiator selects one or more experts, a next step is toestablish a communication link between the initiator and an expert forposting and response (an “information transaction”). A communicationlink may be variously provided, including via email, online chat andinstant messaging. However, a drawback of email is that it relies ontext communication (e.g., typing), with its attendant mechanicalchallenges. Another drawback of email is the time lag (“latency”)between sending an email and receiving a response. Yet another drawbackof email is that it has a low level of interactivity and, as such, tendsto be impersonal, ambiguous and inefficient in communication.Accordingly, email tends to hinder experts in providing a response,particularly one suited to and satisfying of the initiator's needs.

Online chat and instant messaging tend to be more interactive thanemail. Even so, each also again relies on text communication. Moreover,by their nature, chat and instant messaging tend to introduce anemphasis on speed in that text communication (e.g., fast typing). Thisemphasis generally is undesirable. Indeed, this emphasis can be asubstantial hindrance for people either who are not familiar or adeptwith keyboards, who are physically excluded from keyboard use and/orwhose written language is not based on Roman characters (e.g., thoseusing symbol-based written languages, such as Chinese). Moreover, thisemphasis may be specifically undesirable and the hindrance exacerbatedin the context of an information instruction (e.g., initiators and/orexperts in an information marketplace find the emphasis on rapid typingto be detrimental to an information instruction).

Given these drawbacks, a contemplated information marketplace preferablysupplants or supplements email, online chat and instant messaging withother forms of Internet-based or Internet-related communication. Suchforms of communication typically rely—at least in part—on voicecommunication. These forms include audio and/or audio/videoconferencing, with or without text communication. These forms aredesirable in their enhanced interactivity, reduced latency andde-emphasis on writing, particularly rapid writing. As such, these formstend to provide more personal, direct, clear and efficientcommunication. These forms are simply more natural. Accordingly, theseforms tend to be particularly desirable for initiators and experts alikein the context of an information marketplace.

Although voice communication tends to be more direct, efficient andotherwise desirable than e-mail, chat, and instant messaging, voicecommunication also tends to have some drawbacks. In particular, voicecommunication generally is subject to a lower level of anonymity(whether real or perceived) than is typically associated with each ofemail, chat and instant messaging.

Anonymity typically characterizes interaction and other communicationvia the Internet. For example, people are enabled to interact andotherwise communicate in cyber space without revealing much, if any,personal information, such as legal names or phone numbers.

Internet users tend to prefer anonymity for various reasons. As anexample, an employee using the Internet to search for a new job desiresanonymity so as to preclude any revelation of their identity to acurrent employer, supervisors and/or colleagues. As another example, anindividual who has provided personal financial data to an online plannermay desire anonymity so that the data is not associated with theindividual's identity (such association potentially transforming the rawdata into valuable information). As yet another example, members ofInternet communities use various kinds of substitute names (e.g.,aliases, nicknames or user names) in communicating with each other.

The shortfall of anonymity in voice communications—particularlyconversations conducted via the standard telephone system—tends tointroduce problems with privacy, particularly expectations of privacy. Acommon such problem is the receipt of unwanted phone calls. Theseunwanted calls can be annoying (e.g., telephone calls fromtele-marketers), disturbing (e.g., contact from objectionable politicalorganizations) and even frightening (e.g., intrusions from ostensiblydangerous individuals). Perhaps because voice communication is direct,unwanted calls tend to be difficult to terminate. Perhaps becausetelephone conversations are more personal, people tend not to fullyblock, automatically reject or otherwise absolutely deal with calls fromunknown sources, which calls have a tendency to be unwanted but whichcould cause desirable or important calls to be missed (e.g., a friend offamily member calling for emergency assistance).

Based at least in part on concerns about unwanted calls, people remainreluctant to disclose their phone numbers, particularly their hometelephone and personal cellular numbers. This reluctance also tends toreflect, at least in part, the perception that phone numbers enable therecipients to more readily discover personal information about theperson that disclosed the number, such as name and physical address.This reluctance also tends to result in slow acceptance and lesser useamong Internet users of voice communication (i.e., as compared to email,chat and instant messaging), whether such communication isInternet-based or Internet-related (e.g., via standard telephone service(also known as the plain old telephone system (“POTS”)), but initiatedby or in connection with Internet services).

It is desirable, then, to integrate voice communication and anonymity.An example of such integration may be illustrated in the context of aninformation marketplace. There, an initiator determines to conduct aninformation instruction with a selected expert via voice communication.To do so, the initiator submits a request for voice communication withthe selected expert, the submission being through the Internet to theoperator or other infrastructure of the information marketplace (orother service or system that supports linking by voice communication).The marketplace contacts the selected expert. The contact may be via (a)the Internet, so as to support voice communication as voice overInternet protocol (“VoIP”) or (b) telephone service. In either case, ifthe contact results in establishing a voice communication link with theexpert, the marketplace maintains that link (e.g., puts the expert onhold) while establishing voice connection with the initiator beforeconnecting the expert and the initiator. The marketplace makes thatconnection, in one case, by linking the initiator and the expert overthe Internet, with the marketplace either interposed in the transmissionof packets or enabling direct transmission. In another case, themarketplace bridges between the initiator communicating over theInternet (e.g., VoIP) and the expert communicating via standardtelephony. In yet another case, the marketplace connects by contactingthe initiator by telephone and, once the initiator is on the line,connecting the initiator with the expert who is also linked bytelephone. In each and any case, a connection is made and voicecommunication is enabled, characterized by enhanced support foranonymity.

Integration of anonymity and voice communication in this form tends tohave shortfalls. One of the shortfalls is that a party may be contacted,without advance notice and at any time by the marketplace, responsive toany initiator's request. That scope of contact tends to deprive thecontacted party of control over their respective schedules, which inturn, tends to degrade productivity and efficiency in their work and toreduce the quality of their personal time. Indeed, without advancenotice of calls in an information marketplace, an expert may be inducedto keep the telephone proximate at all times, so as to either take callsin interruption of other work or play and/or to forestall work or playin anticipation of calls (e.g., calls that might never arise). Thistends to have enhanced relevance in the commercial or professionalcontext, wherein the expert seeks to provide high quality and highlyresponsive service to clients (e.g., initiators) so as to, among otherthings, keep clients satisfied and otherwise happy with the providedservices (e.g., to avoid unanswered calls).

One solution to this shortfall is to support specified times and/or timerange(s) during which a party (e.g., an expert of an informationmarketplace) is committed to be available for receipt of calls from theinformation marketplace. In the information marketplace, these times andranges are office hours. During an expert's office hours, the expertcommits, or even guarantees, to be present to receive calls from themarketplace. At the same time, the expert benefits by enhanced knowledgeof and personal control over, when such calls, if any, may arise.

This solution, however, also has shortfalls. In the informationmarketplace, one shortfall is its tendency to reduce, from an alreadyfinite number of experts available via the marketplace, the number ofexperts actually available at any given time. That is, at any giventime, it is to be expected that, via the marketplace, less than all ofthe experts are within their office hours. Moreover, even if aparticular expert is within their office hours, a reduced supply ofexperts will tend to reduce the frequency at which requests result in aconnection (e.g., the expert will have an increased chance of being busywith another, earlier initiator).

Another shortfall is that the initiator will generally attempt tocontact the expert promptly, if not immediately or substantiallyimmediately, after indicating interest in contact, and this might not beconvenient for the expert even if the initiator attempts to make contactwithin the expert's office hours.

As another example, a service or system supporting integration mayassign individuals and entities respective user codes, each of whichuniquely identifies the particular user. To support such codes, theservice/system stores the codes, e.g., in one or more databases.Preferably, the service/system associates the codes with the telephonenumber and/or contact information of the respective individuals andentities.

The service/system may use the user codes variously. For example, in avirtual chat room context, the service/system may enable participants toplace an advertisement (e.g., in a publication, such as a physical orvirtual magazine) carrying the telephone number of the marketplace andciting the user code. In that circumstance, an observer of theadvertisement may contact the participant by placing a telephone call tothe marketplace and entering the user code. The service/system thenestablishes the communication link to the participant, e.g., by placingthe observer on hold, retrieving the participant's telephone number byassociation with the user code, contacting the participant and, once theparticipant is contacted and found to be available, connecting theparticipant with the calling observer. In this manner, the observer doesnot know the actual phone number of the participant, thus preserving theparticipant's anonymity.

This design is suitable for chat rooms where participants talk to eachother casually, and the system only needs to identify differentparticipants. However, user code is not sufficient to identify anddescribe different transactions having different transactionspecifications and connection criteria among participants, as in thecontext of an information marketplace where participants buy and sellinformation.

As still another example, a service or system supporting integration ofanonymity and voice communication may assign each user a contact code,the contact code identifying each user as a party to a scheduled voicecommunication. The contact code may be one or more groups ofalphanumeric characters (e.g., if the contact code comprises a call codeand password, it may be provided as one or two numbers). In supportingcontact codes, the service/system enables the parties to place separatetelephone calls (through the public switched telephone network or viathe Internet) to the service/system (or related infrastructure) at ascheduled time. Upon connection with the service/system, each partyenters their respective contact codes (e.g., through their telephonekeypads). The service/system compares the contact codes entered by theparties and connects the telephone calls if the contact codes are proper(e.g., the codes must either match exactly or match in accordance withpredetermined criteria).

Yet another example is an extension of the contact code feature. In thiscase, the service/system creates, after the first successful connectionbetween two parties, a record indicative of these two parties and/or ofthe connection. Based on that record, the service/system may beconfigured to connect either party to the other when, in the future, oneparty dials into the system and inputs their contact code. That is, theservice/system places a call to the non-calling party, rather thanrequiring the non-calling party to dial in. In such case, theservice/system may be configured to support (a) provision of informationto the called party about the calling party, e.g., upon theservice/system contacting the called party, (b) a request that thecalled party enter their contact code, (c) a combination of these. Theservice/system may be configured so that either or both parties mayelect in or out of this feature.

In addition to the shortfall of using user code, this method requiresparticipants placing separate phone calls to the service/system at thesame time.

SUMMARY OF THE INVENTION

It has now been recognized that the services/systems described above donot allow one or more parties to specify the nature of the transaction,e.g. with respect to time or time interval, billing arrangements, andother variables.

In accordance with a first aspect of the invention there is provided amethod of facilitating anonymous voice communication between a firststation and a second station, at least the second station having anaddress for voice communication, the method comprising providing aninterface that allows input of a transaction specification from at leastone of the first and second stations, generating a reference codeassociated with the transaction, there being a defined relationshipbetween the reference code and said address, supplying the referencecode to at least the first station, receiving a voice communicationrequest from the first station, receiving the reference code from thefirst station, using the reference code to recover said address, andopening a channel for voice communication between said first and secondstations, whereby voice communication can be established between thefirst and second stations without providing said address to the firststation.

In accordance with a second aspect of the invention there is provided amethod of establishing anonymous voice communication between a firststation and a second station, at least the second station having anaddress for voice communication, the method comprising supplying atransaction specification from at least one of the first and secondstations to a controller, generating a reference code associated withthe transaction at the controller, there being a defined relationshipbetween the reference code and said address, supplying the referencecode from the controller to at least the first station, making a voicecommunication request from the first station to the controller,supplying the reference code from the first station to the controller,using the controller to recover said address from the reference code,and opening a channel for voice communication between said first andsecond stations.

In accordance with a third aspect of the invention there is provided anapparatus for facilitating anonymous voice communication between a firstparty and a second party, at least the second party having an addressfor voice communication, including a means for enabling negotiation of atransaction specification, a means for generating a reference code,there being a defined relationship between the reference code and saidaddress, and for supplying the reference code to the first party, ameans for receiving a voice communication request from the first partyand for receiving the reference code from the first party, a means forusing the reference code to recover said address, and a means foropening a voice communication channel between said first party and saidaddress without supplying said address to the first party.

A preferred embodiment of the invention facilitates anonymous voicecommunication between parties involved in online transactions.

In a preferred embodiment of the invention, either/both parties are ableto schedule individually or in coordination one or more future (and/orimmediate) appointments for voice communication while preservinganonymity.

A preferred embodiment of the invention allows transacting parties tospecify their mutually agreed connection criteria, such as connectiontime frame, which party should initiate the connection, charging methodand duration of the communication. Referring to the example of an expertcommunity, experts are not restricted to their office hours withoutknowing when, if ever, they will be contacted by the system forservicing a user request. On the other hand, users would be able to haveaccess to all registered experts without having to wait for their officehours because both parties can set up mutually agreed upon appointmenttime for voice communication.

In various forms of integration of voice communication and anonymity,one or more additional features may be desirable. As an example, aservice or system supporting integration may provide a transactiontracking mechanism and/or process that enables identification andcataloging of a user's various transactions. Such mechanism and/orprocess responds to the fact that a given user may have a history oftransactions and, at any given time, may be involved in severaltransactions, with each such past and current transaction typicallyhaving different attributes and connection criteria.

To illustrate by scenario, users A, B and C are participants in aninformation marketplace. In the marketplace, participant A is an expertin both career planning and fishing. Participant A is counselingparticipants B and C, individually, as to career planning, with theassistance being provided via anonymous voice communication. ParticipantA is also advising participant C as to fishing skills, which advice ifprovided via email. Participant A charges different fees to participantB than to participant C for career planning, based on the differingcomplexity of the cases. Participant A charges participant C a muchlower price for the fishing advice. Moreover, participant A counselsparticipants B and C during daytime hours, while responding to C onfishing skills only during evening hours. Participant A also placesrestrictions on the times during which participants B and C arepermitted to make contact for career counseling.

In the above scenario, the transaction tracking mechanism/processpreferably is implemented so as (a) to differentiate among transactions,even if the transactions are between the same two participants and (b)to track, for each such transaction, the transaction's attributes, suchas, but not limited to, fees or other pricing, elapsed time, connectiontype (e.g., voice, chat, email, etc.), and scheduling.

In a preferred embodiment of the invention, relating to this example, areference code is associated with each transaction. The use of atransaction specific reference code makes it possible to manage eachvoice communication event individually according to connection criteriaagreed by transacting parties. Assigning a reference code to eachtransaction provide more manageable flexibility. For example, user A canrequest to be connected to B and C separately. Since these twotransactions have different reference codes, the system would know howto charge B and C differently for the connection. User C is to beconnected with at least twice, once for career coaching and once forfishing tips. With different reference codes, the system is able todistinguish which connection is for career coaching and which is forfishing tips, and therefore, charge C accordingly.

A service or system supporting integration preferably offers networkflexibility. Preferably the service/system is Internet-based, but alsocompatible with circuit-switched networks. In addition, theservice/system preferably is not restricted to circuit-switched networksfor establishment of communication links between parties, particularlyfor voice communication.

Still further, a preferred embodiment of the invention provides a methodand apparatus to guarantee fulfillment of pre-agreed criteria of thetransaction specification. For example, in a preferred embodiment of theinvention the connection can only be established during a pre-agreedconnection time frame. Connection request outside of the pre-agreed timeframe may be rejected. This time frame, as an attribute of thetransaction specification, is inputted by the user and stored in adatabase. This information can be retrieved from the database using thereference code. A controller unit qualifies the connection according tothe transaction specification, such as the pre-agreed appointment time.The controller unit also monitors the connection and generates logs,which can be used to bill the user based on pre-agreed rate.

A preferred embodiment of the invention provides an automated processfor end users to be connected automatically without manual input. Theprocess of obtaining the reference code, connecting to the controllerunit and inputting the reference code can be automated by a softwareprogram or hardware component in the communication device of the user.Therefore, with a click of a button, the user is anonymously andautomatically connected with the other party for voice communication.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the invention, and to show how the samemay be carried into effect, reference will now be made, by way ofexample, to the accompanying drawings, in which

FIG. 1 provides a conceptualized illustration of the anonymousconnection system,

FIG. 2 shows a simplified diagram of an Internet based communicationsystem,

FIG. 3 provides a block diagram showing one embodiment of the controllerunit,

FIG. 4A illustrates an embodiment showing the process of how a referencecode is generated for each anonymous voice communication request fromend users,

FIG. 4B illustrates an embodiment of the process to establish anonymousconnection between two parties using the reference code,

FIG. 5 shows an exemplary user interface for the reminder function, and

FIG. 6 shows an exemplary user interface to utilize the automaticconnection function.

DETAILED DESCRIPTION

Turning to the Figures, FIG. 1 illustrates one service/system thatintegrates voice communication and anonymity. The system comprises (a)devices 14, 16 capable of transceiving packet data (henceforth referredto as “internet-enabled devices”), (b) a packet data network 18, (c) acommunication network 30, (d) voice-enabled devices 26, 28, (e)controller unit 24, and (f) at least one server 20, 22. Theinternet-enabled devices 14, 16 can be variously implemented, including,without limitation, as desktop or laptop personal computers, as Internetappliances, and as PDAs or other handheld devices (e.g., smart phoneswith Internet accessibility). Voice-enabled devices 26, 28 enable users10, 12 to conduct voice communications.

It is to be recognized that, although devices 14, 16 are shownseparately from corresponding devices 26, 28, the functions of therespective devices may be provided via one apparatus, without departingfrom the principles of the invention. To illustrate, the devices 14 and26, as well as the devices 16 and 28, may be integrated, e.g., as aWeb-enabled digital cellular phone, and/or a connected personal computerwith a speaker and microphone. Dotted lines 15 are set forth to indicatethese configuration options.

The packet data network 18 typically is a packet switched network andpreferably operates using open protocols. The network 18 generally isthe Internet, but it can also comprise other publicly availablenetworks, as well as private networks, such as a local area network(LAN) and/or an intranet. The packet data network 18 can also be acombination of these types of networks, or otherwise, so long as itprovides the functions described herein.

The servers 20-22 may be variously implemented provided they support thefunctions described herein and, in particular, support the integrationof voice communication and anonymity. Accordingly, servers 20-22 may besingular or plural in number.

The servers 20-22 preferably comprise Web servers implemented to host atleast one and typically plural Web sites. Generally, such servers 20-22host the front ends of such Web sites, which typically are otherwiseindependent (e.g. separately owned and/or operated) of the servers20-22.

It is to be recognized that the servers 20-22, in providing a service toindependent Web sites, may also be implemented to support (directly orindirectly) features, functions, services and applications other thanthe integration of voice and anonymity. That support reflects that thehosted Web sites may offer a variety of features, functions, servicesand applications (e.g., information marketplaces). These features,functions, services and applications may be recognized by users whoaccess one or more of the Web pages typically comprising a hosted Website. These features, functions, services and applications may also beunrecognized by (or even hidden from) users, such as, as examples,directory service, database inquiry, transaction processing, andsecurity monitoring.

It is also to be recognized that the servers 20-22 may enablecommunication other than by voice. As such, the servers 20-22 maycomprise email, fax, text messaging or other servers operating viapacket data network 18. It is also to be recognized that the servers20-22 may comprise gateways to the communication network 30, such as toprovide voice messaging. In this latter example, the servers 20-22 maysupport either/both voice recognition (e.g., to acquire and identify allor part of incoming messages) and/or voice synthesis (e.g., to delivermessages with users, either in established network mailboxes or forpersonal delivery to the user or their message machine).

Controller unit 24 typically is implemented to manage and coordinateoperation of the service/system so as to integrate voice communicationand anonymity. In the case of an information marketplace, the unit 24preferably provides for establishment of communication links between aninitiator and an expert, particularly when the initiator requests voicecommunications, and while ensuring the anonymity of either/both theinitiator and/or the expert.

Communication network 30 may be variously implemented. In oneembodiment, the network 30 comprises a conventional, circuit-switchednetwork (e.g., the public switched telephone network (“PSTN”)). Inanother embodiment, the network 30 comprises a packet-switched network,such as the Internet, supporting VoIP. In still another embodiment, thenetwork 30 comprises a private data network which embodiment tends toprovide an enhanced service level (e.g., quality of service). In yetanother embodiment, the network 30 is optimized to employ a combinationof one or more of the above-described embodiments, depending on factorssuch as what technologies are available to each user, quality of serviceneeds, user convenience, costs incurred and fees charged (e.g.,user-selected fee rates), and the like.

It is to be recognized that although the communication network 30 andpacket data network 18 are illustrated as separate elements in FIG. 1,the communication network 30 may be integrated with the packet datanetwork 18. As an example, the communication network 30 need not be acircuit switched network. Moreover, the packet data and communicationnetworks 18, 30 may be implemented using some or all of the sameinfrastructure. In a specific example, the networks 18, 30 may both beimplemented to support TCP/IP or otherwise deploy or support theInternet in order to transmit data (e.g., the signals described above)and voice communication (e.g., VoIP).

The above-described components of the service/system are coupled amongone another by wired or wireless technologies, or both. From coupling tocoupling, these technologies may comprise network equipment, such as,but not limited to, servers, modems, routers, bridges and gateways. Suchnetwork equipment is well known and understood by one of ordinary skillin that art and, as such, is not shown in FIG. 1.

Various signals are transmitted between and among components of theservice/system. The signals include transaction specification 32,connection instruction 34, reference code 36, and communication record40.

Transaction specifications 32 include specifications, characteristicsand other parameters (referred to sometimes hereafter, in the context oftransaction specifications, individually and collectively as“parameters”) associated with and describing a proposed transaction.These parameters preferably include the type of product/service beingexchanged, the quality of the product/service, fees or other price, ifany (e.g., pre-agreed fees), delivery or appointment time(s), and otherrelated requirements. These parameters preferably also includes anindication as to whether there is a request for anonymous voicecommunication and/or any other specification of whether the transactionis to comprise voice communication. These parameters may also includeadditional information sought by the service/system, such as to obtaininformation (a) omitted from submitted transaction specification(s), (b)related to submitted transaction specifications, (c) sought by theservice/system, and/or (d) combinations of these. Additionalinformation, as an example, may include data as to which user initiatesan appointed transaction wherein voice communication isrequested/accepted and/or the related contact information for use by theservice/system to preserve anonymity in establishing the connection forthe applicable communication.

Transaction specifications 32 may be obtained from various combinationsof user(s). As one example, only one of the users 10, 12 provides atransaction specification 32 in connection with a particulartransaction. In such case, a user that does not provide a specification32 typically will have furnished the same, similar or sufficientinformation, in advance, to the service/system. That informationpreferably is relevant to transactions generally (e.g., fees, timesavailable, etc.). Also, that information may be provided actively (e.g.,by completing information requests of the service/system) or passively(e.g., by the service/system's collection of data and/or data mining ofsame in the context of the user's history of transactions). In havingfurnished such advance information, a user is relieved of providing atransaction specification 32. It is to be recognized, however, that thisrelief may be case-by-case (e.g., as to specific transactions, orparameters thereof, such as, a listed user) and/or time-to-time (e.g.,as to transaction posed for certain time frames), such that, in anyparticular case or time, this user may ultimately submit a transactionspecification 32 (e.g., when polled by the service/system).

In an alternative, one user may be relieved of providing a transactionspecification because the system/server effectively provides that user'stransaction specification. This circumstance may arise variously, e.g.,based on the business model or other operation standards of theservice/system. In a particular case of this alternative, thesystem/server or either/both users may establish that only thetransaction specification 32 of the user initiating communication is tobe obtained/recognized (e.g., in an information marketplace, theinitiator's transaction specification 32 controls). In anotherparticular case, the system/server or either/both users may establishthat only the transaction specification 32 of the user sought forcommunication is to be obtained/recognized (e.g., in an informationmarketplace, the expert's transaction specification 32 controls). In anycase, the relief may be case-by-case and/or time-to-time, as describedabove.

As an extension of the above, the service/system also supports operationwherein neither party provides transaction specifications 32. Inaccordance with the above, this extension responds to both usersproviding advance information relevant to transaction specifications 32.Based on that information (and perhaps responsive to observed patternsof a user's conduct, e.g., Web surfing), the service/system determinesone or more transactions that may be available and/or appropriate to theusers. Preferably, the service/system provides to each user theparameters of the transaction(s) available to the respective user (e.g.,via servers 20-22, as Web-page content, as an email, as an instantmessage, as a fax (Internet- or POTS-based), and/or as a voice message).The service/system may be implemented to schedule a particulartransaction, or suggest a schedule for same.

As another example, both users 10, 12 provide transaction specifications32. This example admits various cases. In one case, the transactionspecifications 32 are the same. This case applies where thespecification have character-by-character congruence. This case alsoapplies where one user acknowledges the other's specification, eitherexplicitly or tacitly (e.g., where the specification is negotiated toagreement between the parties in advance, as described further below).This case yet also applies where one user abdicates, for whateverreason, to the other user's specification.

In another case, the transaction specifications are different. In thiscase, one or both user(s) may provide information, which is specific tothat user or otherwise irrelevant to, outside the knowledge of, and/ornot assigned by the service/system to be provided by, the other user. Toillustrate, each user may provide a user name and/or contact informationthat differs from the other. To illustrate further, one user may providedata about the transaction that is required solely from that user by theservice/system (e.g., in the context of an information marketplace, anexpert is required to provide a curriculum as to the instanttransaction). In either such case, the service/system may participatesimilar to as described above when one or no user provides transactionspecifications 32 to relieve one or both users from having to providecertain information in the respective transaction specifications 32(e.g., the same or different information for each user), including, ornot, from case-to-case and time-to-time.

Transaction specification(s) 32 may also involve various processes. Asan example, one or more users may submit a transaction specification 32based on negotiation with the other user and/or the service/system. Thenegotiation may be conducted via a communication network (e.g., POTS orfax) and/or a packet data network (e.g., email and/or instant messaging)and/or otherwise. In one alternative, the negotiation may be conducted,in whole or in part, via the service/system. In one form of thisalternative, the negotiation may be conducted via the transactionspecifications 32, where these specifications are submitted and, asnecessary, iteratively re-submitted by each of the negotiating users(and/or the service/system) toward reaching agreement. At the same time,the negotiation may be conducted via the service/system other thanthrough use of the transaction specifications 32. In any case, any suchnegotiation preferably culminates in each submitting user's submissionof a transaction specification that is final to the transaction.

In any case, a negotiation generally implicates some or all of theparameters of the transaction. Following negotiation of the implicatedparameters, the submitting users preferably submit respectivespecifications 32 reflecting the agreements with the other users and/orservice/system. If not all parameters are negotiated to agreement; thesubmitting users may submit the transaction specification 32 based on animplementation wherein the service/system arbitrates the undecidedparameters. In such case, the service/system may be implemented not onlyto arbitrate the undecided parameters, but also to mediate agreement onsuch parameters (e.g., by providing alternatives of same to users),and/or to determine such parameters and/or to suggest changes ordetermine changes to otherwise agreed on parameters.

In the context of an information marketplace, an initiator and expertmay engage in a negotiation process toward agreeing on the parameters ofone information transaction (or plural information transactions), andsubmission of one or more specifications 32 relating to the informationtransaction. The negotiation may involve give and take by bothparticipants. On the other hand, the negotiation may be straightforward,such as if the expert simply accepts the parameters proposed by theinitiator, or vice versa (e.g., the initiator may accept all theparameters set forth by the expert via Web pages or otherwise via theservice/system). In this context, the participants may submitseparate-but-congruent transaction specifications, or they may submitonly one transaction specification between them, with the non-submittingparticipant either acknowledging that specification (e.g., an expressindication that the participant has reviewed and approved thespecification) or not.

The transaction specification(s) 32 preferably are obtained through thepacket data network 18. More specifically, the transactionspecifications preferably are obtained via servers 20-22, e.g., as Webpage content, as email, as instant message, as an Internet-based faxand/or otherwise. However, the transaction specifications may beobtained via the communication network 30, e.g., as POTS-based faxand/or as a voice message. In this latter aspect, the transactionspecifications preferably are obtained and recognized automatically,e.g., through voice and or character recognition.

A connection instruction 34 provides information on a proposedconnection between users 10, 12. A connection instruction's informationmay be variously configured, e.g., from service/system toservice/system, or from type to type. As an example, a connectioninstruction 34 may include one or more of a connection's type (e.g.,email, chat, voice, video, etc.), time frames (e.g., day/date forinitiation and conclusion), connection process (e.g., which user(s)initiate, via what network(s) and how), charging method (e.g., byduration, connection time or fixed sum) and contact information (e.g.,phone number, IP address, domain name, Web server information, securityinformation, chat alias and/or email address). Generally, the connectioninstruction(s) 34 include contact information of at least one user inthe proposed communication.

As an illustrative example, the servers 20-22 provide one or moreconnection instruction(s) 34 in association with an applicabletransaction between users 10, 12. The servers 20-22 preferably generateconnection instruction(s) 34 based on and/or responsive to one or moretransaction specifications 32. The servers 20-22 may also generateconnection instruction(s) 34 based on and/or responsive to informationstored within the service/system, such as within databases associatedwith one or more servers 20-22 (e.g., user profile databases). Thislatter information may include, as non-exhaustive examples, either/bothassociated billing preferences and/or contact information.

The servers might not have access to the same transaction instruction(s)and/or the same information from other sources, including databases.Accordingly, a transaction may associate with plurality of connectioninstructions 34. These instructions may not be equivalent. Typically,however, they are complementary or supplementary of one another.

Also as an illustrative example, a connection instruction 34 isassembled from information extracted from one or more transactionspecifications 32. In the specific case of transactions involving voicecommunication, one or more servers 20-22 extract information relevant tovoice communication (e.g., voice communication request, connection timeframe, payment method, who initiates the call, etc.) and assemble thatinformation into one or more connection instructions 34. Theseconnection instructions 34 may provide for voice communication incombination with one or more other forms of communication.

If the transaction specification 32 directs other than voicecommunication, the applicable servers 20-22 extract and assemble aconnection instruction 34 relevant to that communication type. In thislatter case, however, the service/system may also be implemented toprovide connection instructions 34 that cover voice communication (i.e.,even if not originally requested). To do so, the service/system mayprovide the information for voice communication either in a separateconnection instruction or integrated in one connection instruction.

Servers 20-22 preferably forward connection instructions 34 to thecontroller unit 24. It is to be recognized that the controller unit 24may receive connection instruction(s) from multiple, independentservers. It is also to be recognized that the controller unit 24 may beimplemented to generate connection instructions, either instead of or inconjunction with the servers 20-22 (e.g., where transactionspecifications are obtained via the communication network 30, e.g., asPOTS-based fax subject to character recognition and/or as a voicemessaging subject to voice recognition). In this latter case, theconnection instructions 34 preferably are based on and/or responsive toone or more transaction specifications 32, together with or apart frominformation stored within the service/system, such as within databasesassociated with one or more servers 20-22 (e.g., user profiledatabases).

The controller unit 24 preferably stores the connection instruction(s)34. The storage can be variously implemented, e.g., in format, durationand/or comprehensiveness. As an example, the storage may be terminatedafter the applicable communication is completed, so as to erase theassociated information. As another example, only a portion of thestorage may be terminated and/or some information archived, with anyretained information used for various purposes, e.g., such as forbilling or tracking purposes.

The controller unit 24 preferably also is implemented to generate one ormore reference codes 36 in association with an applicable transactionbetween users 10, 12. The controller unit preferably generates thereference codes 36 based on and/or responsive to one or more connectioninstructions 34. In that, each reference code 36 preferably correspondsuniquely to the implicated connection instructions 34.

It is to be recognized that the controller unit 24 may also generatereference codes 36 based on and/or responsive to information storedwithin the service/system, such as within databases associated with theunit 24 and/or one or more servers 20-22 (e.g., user profile databases).This generation may be apart from or, preferably, together with one ormore connection instructions 34.

It is also to be recognized that the controller unit 24 may beimplemented to generate reference codes based on and/or responsive toinformation obtained directly from one or more transactionspecifications 32. The unit 24 may so generate together with or apartfrom one, plural or all connection instructions 34. The unit 24 may sogenerate together with or apart from some or all information storedwithin the service/system (e.g., contact information).

In any case, reference codes 36 preferably are generated in associationwith transactions so as to uniquely correspond thereto. In particular,reference codes 36 preferably are generated to enable the connectionprocess associated with transactions. In addition, reference codes 36are generated to enable tracking of transactions. As to the latter, ininformation marketplaces, reference codes provide for tracking a user'sinformation transactions and, in particular, enable identification andcataloging of such user's various information transactions. Aspreviously described, tracking responds to the circumstance that a userwill tend to have a history of transactions and, at any given time, maybe involved in several transactions, with each such past and currenttransactions typically having different attributes and connectioncriteria. Tracking transactions preferably is implemented so as (a) todifferentiate among transactions, even if the transactions are betweenthe same two users and (b) to record, for each such transaction, thetransaction's attributes, such as, but not limited to, the parametersand other information associated with transaction specifications and/or,if any, connection instructions and/or other service/system information(e.g., fees or other pricing, actual elapsed time).

Reference codes 36 may be variously implemented. In one implementation,reference codes 36 comprise one or more, and generally combinations of,letters, numbers and symbols. In other implementations, reference codes36 may comprise graphics, images, video, and voice patterns, orcombinations of these, with or without any letters, numbers or symbols.Reference codes may comprise one or more groups of the above, (e.g., ifthe reference code comprises a code body and password, it may beprovided as one or two sets of numbers, letters, etc.). Reference codesmay also be provided variously to user(s), including, as examples,visually (e.g., by screen display, printed document, video), audibly(e.g., by voice or voice mail) or by methods hidden from a user'sperception.

In addition to generating reference codes 36, the controller unit 24preferably also provides for storing such codes. The storage can bevariously implemented, e.g., in format, duration and/orcomprehensiveness. As an example, the storage may be terminated afterthe applicable communication is completed, so as to erase any or allassociated information. As another example, only a portion of thestorage may be terminated and/or some information archived, with anyretained information used for various purposes, e.g., such as forbilling or tracking purposes and/or so that reference codes can berecycled for use in future transactions. (Storage of reference codes isfurther described below in connection with reference code database 100.)

In addition to generating reference codes, the controller unit 24preferably also provides for transmission of reference codes to one ormore users in the applicable transaction. Preferably, the unit 24 soprovides via the packet data network 18. As an illustrative example, theunit 24 so provides by furnishing the respective codes 36 to one or moreselected servers 20-22, enabling the servers 20-22 to transmit the codes36 to respective users 10, 12 via the network 18. The selected servers20-22 may be Web servers, email servers, chat servers, Internet-faxservers or otherwise. In the case of a Web server, the user preferablyis enabled to access the codes either audibly, visibly and/or in asecure, hidden form (e.g., so that only the system—preferablyauthenticated—recognizes and can act on all or certain of the codes).

It is to be recognized that the unit 24 may be implemented to providethe reference codes via the communication network 30, together with orapart from provision via the packet data network 18. In thisimplementation, the unit 24 preferably transmits the codes via a PSTNgateway (e.g., for voice or standard fax transmission). In voicetransmission, the unit 24 typically employs voice synthesis forcommunication and, preferably, has access to voice mail, eitherPSTN-supported or via a subscriber's private answering machine.Provision of the reference codes via the communication network 30 may betogether with, or apart from, provision of such codes via the packetdata network 18.

In the provision of references codes 36 to users, various approaches maybe taken, particularly based on enabled and/or applicable connectionprocesses. In one example, an information marketplace may be implementedso that (a) the initiator receives a reference code, but the expert doesnot, or (b) the expert receives a reference code while the initiatordoes not, or (c) both parties receive the reference code, or (d) neitherparty receives the reference code (e.g., a form of immediateconnection).

In their provision to users, the reference codes 36 typically enable theconnection process. In one example of a connection process, one or morereference codes are provided together with contact information. Inanother example of a connection process, one caller may be volunteered,assigned or otherwise designated to initiate contact (the “designatedcaller”). The designated caller typically initiates contact with theother user via the controller unit 24, particularly through one or bothof the packet data or communication networks 18, 30. In doing so, thedesignated caller typically submits their reference code. Thatsubmission may be accompanied, or not, by the other user submittingtheir reference code.

In the connection process, the submission of reference codes may beaccomplished variously. As examples, a user may submit reference codesby voicing the reference code (e.g., via VoIP or POTS), by keying in thecode (e.g., for Internet submission via chat, email, or the like, or forPOTS submission via tone or pulse coding), or combination or otherwise.

The service/system receives the reference codes so entered by one ormore users and determines whether the codes are proper. If the enteredcodes are proper, the service/system establishes connections (e.g., VoIPand/or telephone calls) between/among users. Codes may be proper undervarious criteria (e.g., all or part of the entered codes matches exactlyanother entered code (or part thereof) and/or matches such other enteredcode under predetermined criteria and/or matches exactly, matches underpredetermined criteria or is otherwise in accord with code records).

The connection process typically includes, but is not limited to,receiving, storing, inputting and processing reference codes. Althoughthe process above describes user input of reference codes, theconnection process may be entirely or partially automated, e.g., byusing a software program or hardware component in a user's communicationdevice and/or in connection with the controller unit 24 or servers20-22.

In the connection process, a controller unit 24 preferably retrievesconnection instructions) 34 associated with a transaction identified toa received reference code. The connection instructions 34 typically arepreviously stored in a database associated with the unit 24 and/or withone or more servers 20-22. The connection instructions 34 are retrievedso as to enable connection management (e.g., by the controller unit 24)of the connection associated with the received reference code.

In an example of management by the unit 24, the unit 24 connects thedesignated caller to the called party using contact information. Inanother example, the controller unit may reject the designated caller'srequest for voice connection with the other transacting party if thecalling time does not satisfy a pre-agreed calling time frame. In yetanother example, the controller unit 24 generates communication records40. The unit 24 typically generates such records, e.g., during theconnection, via monitoring the transaction (e.g., particularly voicecommunications supporting anonymity). The communication records 40typically include various data associated with transactions, e.g., theidentities of communicating parties, billing information, transactionreference code (for the purpose of identifying each specifictransaction), the starting time and duration of the communication, amongother data.

FIG. 2 illustrates an example of a communication network 30 (shown inbox 78) and an example of voice-enabled devices (shown in boxes 80(a)and 80(b)). Here, the communication network 30 employs the Internet 50,and comprises one or more of each of Internet access points 66, publicswitched telephone networks (PSTN) 58, PSTN gateways 52, mobileswitching offices 60 and other mobile infrastructure, such as basestations 62. Although the illustrated network 30 employs the Internet(actually or effectively a public network), it is to be recognized thatthe network 30 may be implemented to employ one or more privatenetworks. Such private networks may be employed together or apart fromany public network, such as the Internet. Such private networkstypically are employed to provide features, functionality or performancethat may not be available through a public network, e.g., to ensurequality of service and/or provide security features.

PSTN gateways 52 provide an interface between the PSTN 58 and theInternet 50. The PSTN gateways 52 preferably provide a voice gradeinterface. The PSTN gateways 52 typically comprise one or morecomputers, switches and/or similar equipment for processing telephonecalls. The PSTN gateways typically perform various functions such as (a)the conversion and compression of analog signals from the PSTN todigital signals for transmission via the Internet 50 and (b)decompression and conversion of digital signals received via theInternet 50 into analog signals for transmission via the PSTN.

In FIG. 2, traditional telephone terminals 54, 56, 70, 72 illustrateimplementations of one or both voice-enabled devices 26, 28. Theseterminals 54, 56, 70, 72 are connected to PSTN 58. The PSTN system 58typically comprises multiple control and switching points that areconnected via trunk circuits and signal links.

Wireless terminals 64, 74 illustrate other implementations ofvoice-enabled devices 26, 28. Wireless terminals 64, 74 may comprise anyof screen phones, smart and/or super phones, or wireless PDAs, or othersimilar device. Wireless terminals 64, 74 communicate with base stations62. Base stations 62 typically are fixed in location for communicatingwith wireless terminals within a specific geographical range. Withinthat specific geographic range, base stations 62 may also be responsiblefor coordinating all wireless terminals 64, 74.

In turn, the base stations 62 communicate with a mobile switching office(MSO) 60. The MSO generally is responsible for coordinating activitiesbetween different base stations 62. The MSO 60 is connected to PSTN 58for landline communications.

Personal computers (PCs) 68, 76 illustrate still other implementationsof voice-enabled devices 26, 28. PCs 68, 76 typically comprise desktopor notebook computers equipped with voice input/output devices andvarious software, including application and utility programs directed tocommunication. PCs 68, 76 typically also include a communicationinterface, including, as examples, a modem, ISDN card and/or LANinterface card. Via respective such communication interfaces, PCs 68, 76are connected to the Internet through Internet access point(s) 66.Internet access points 66 generally provide protocol conversions, asnecessary, for two-way data communication over the Internet. Forexample, an Internet access point 66 may comprise multiple modemscoupled to an Internet router, the router providing a ramp with theInternet.

In a communication network 30 configured as in FIG. 2, voice data may betransmitted through the Internet between various terminals (voiceenabled devices). For example, users may establish communication linksbetween traditional telephone terminals, wireless terminals, and PCs.Associated with the network 30 is the controller unit 24, hereimplemented as a node on the Internet. In this association, the unit 24is enabled to manage and otherwise direct voice communication betweenusers. Preferably, in doing so, the unit 24 operates according to one ormore applicable connection instructions 34, and/or other criteriamaintained within the service/system.

The communication network 30 of FIG. 2 is to be recognized as an exampleimplementation. As such, the network 30 may be otherwise configuredwithin the scope of the invention. For example, additional hardware,software and/or other infrastructure may be implemented (e.g. wirelessgateways and appropriate communication protocols), so as to support anenhanced (e.g., more comprehensive) wireless data network and, in turn,so that wireless terminals 64, 74 may be associated with communicationlinks that employ the Internet independently of PSTN.

FIG. 3 illustrates in block diagram form an example implementation ofcontroller unit 24. In this implementation, controller unit 24 comprisesvarious components, including processor 82 (e.g., a microprocessor ormulti-processor configuration), memory 84 (e.g., cache and or otherforms of volatile/non-volatile semiconductor memory), operating system86 (e.g., including a directory service and or to enable operations ofthe controller unit 24), applications 88, voice processing system 89,security system 90 (e.g., to protect private data stored in thecontroller unit), clock system 92, power system 94, network interfaces96, data storage 98 and bus 80 (e.g., to couple the unit's components).

Voice processing system 89 preferably performs one or both of voicerecognition and speech synthesis. The system's synthesis of speechtypically is to articulate voice prompts (e.g., relating or according totext commands). The system's recognition of voice typically is to enablethe controller unit 24 to respond to users' voiced input. That is, withvoice recognition, users are enabled to input, e.g., spoken requests forconnection and/or input of reference codes, such as in the form ofvoiced numbers, letters and words. Where both synthesis and recognitionare implemented, users may interact with the controller unit 24 throughvoice communication, whether the conduit is packet data network 18 orcommunication network 30.

Network interfaces 96 generally enable communication between, on the onehand, controller unit 24 and, on the other hand, networks 18, 30 and/orother elements of an implemented service/system with which the unit 24interfaces, whether directly or indirectly. The interfaces 96 preferablycomprise network adapter infrastructure and, as such, provide varioussignal conditioning/conversion functions. The interfaces 96 typicallyhandle one or more data types, including, as examples, analog, digital,broadband, wireless, and optical data.

Data storage component 98 preferably includes a plurality of databases.Such databases may enable communications, as contemplated herein.Accordingly, one or more databases may be employed in connection with,and/or for the purposes of, scheduling, organizing, establishing,maintaining, tracking and/or otherwise enabling a transaction.

The databases preferably include one or more of the following: referencecode database 100, connection instruction database 102 and communicationrecords database 104. Communication record database 104 may beimplemented to provide various functions, including, as an example,storing communication records 40 for selected current and previoustransactions. The database 104 may also be implemented to store otherinformation, including, as examples, one or more of user codes, contactcodes, connect criteria based on contact codes, and/or analytical data,all as described above.

Reference code database 100 may be implemented to provide variousfunctions, including, as examples: storing reference codes 36 that arereserved or otherwise assigned, tracking reference codes that are incurrent use, identifying reference codes 36 that are to be deleted orotherwise terminated (e.g., after the scheduled transaction orexpiration of some other period of time), identifying or determiningreference codes that are recyclable or otherwise available for use, andotherwise maintaining reference codes 36.

Connection instruction database 102 preferably stores connectioninstructions and/or contact information. The database 102 may beimplemented to store only such contact information of users availablefor voice communication service. However, the database 102 preferably isimplemented to store contact information for any user available forcommunication through the service/system. The database 102 may also beimplemented to store other information, including, as examples, one ormore of user codes, contact codes, connect criteria based on contactcodes, and/or analytical data, all as described above.

The data storage component 98 may also be implemented to support otherdatabases, including outside the controller unit 24. Such databases maystore or provide for information, including, as examples, user codes,contact codes, connect criteria based on contact codes, and/oranalytical data, all as described above.

In an example embodiment employing each of the databases 100, 102, 104,reference code database 100 stores reference codes 36 that are appliedto index some or all of the information stored in either/both ofconnection instruction database 102 and communication records database104. As such, the reference codes are employed for storing, retrievingand/or updating of transaction information of implicated databases 102,104. In operation under this embodiment, processor 82 uses referencecode(s) 36 to generate one or more queries of data storage component 98so as to retrieve information pertaining to that reference code andrelevant to the query, such as information from or relating toconnection instructions 34 and/or communication records 40.

Although controller unit 24 is illustrated using the elements depictedin FIG. 3, it is recognized that this provides only an exampleimplementation of the controller unit 24. It is further recognized thatother implementations exist, such as combinations omitting or replacingsome of the depicted components, and/or adding components.

FIGS. 4A and 4B illustrate an example process for voice communicationsupporting anonymity. In step 110, users conduct one or more on-linetransactions. For these purposes, users typically conduct a transactionvia one or more of the Web, chat, or email. Moreover, a user'stransaction typically is directed to any interaction, exchange or othertransaction involving goods or services, directly or indirectly. Atransaction's goods/services may include, among other things, and notlimited to: hard goods (e.g., electronics, books, and the like),professional services (e.g., travel and employment agency), content(e.g., entertainment such as audio, video, and/or game content),intellectual property (e.g., assignment or licensing of patents,trademarks, copyrights, etc.), knowledge (e.g., research studies),and/or information/data (e.g., domestic sales figures, mortgage rates,etc.). A transaction may involve one or more fees, including a fee forthe service/system and/or a fee for the person or entity that providesgoods or services.

An example context for users conducting on-line transactions is aninformation marketplace. There, as also described above, a user is aninitiator if they post an inquiry. In connection with the posting, theinitiator may also include related requirements, such as a price targetor maximum, a quality characteristic, a preferred delivery method, etc.The initiator generally posts on a virtual bulletin board, e.g.,supported via the Internet. The initiator typically receives a responsefrom one or more other participants (e.g., experts) in the marketplace,which generally is directed to the initiator's requirements, e.g., byproviding a bid. The initiator may select none, one or more of theexperts, typically at their sole discretion. The initiator may alsocontinue the on-line transaction(s) with one or more of the expertstoward negotiating a transaction specification 32 and, if that issatisfactorily accomplished, possibly selecting the expert.

In this example process, users involved in a transaction (“transactingusers”) submit, in step 112, a mutually agreed transaction specification32. As described above, that submission preferably is via servers 20, 22(e.g., Web servers).

In step 116, the example process tests for whether the transactionspecification 32 includes a request for anonymous voice communication(e.g., via immediate or later-scheduled connection). If anonymous voicecommunication is not requested, the transaction proceeds by other means,as indicated by step 118. If anonymous voice communication is requested,server 20, 22 passes, in step 120, one or more connection instructions34 to controller unit 24. In step 122, controller unit 24 stores theconnection instruction 34 (e.g., in connection instruction database102). In step 122, controller unit 24 generates a reference code 36associated with the transaction implicated by the connection instruction34. It is to be understood that, while the controller unit 24 isdescribed for this example process as, in the same step, both storingthe instruction 34 and generating the code 36, the unit 24 may (a)perform those functions in separate steps and (b) may generate the code36 in the absence of the storing activity.

In step 124, the reference code is delivered to one or both of thetransacting users (a “confirmation”). In an illustrative case,confirmations include contact information. In another illustrative case,confirmations may be delivered only to a transacting user assigned toinitiate the communication (e.g., the designated caller in theinformation marketplace context). Confirmations preferably are deliveredthrough packet data network 18, as previously described.

In step 126, the user assigned to place the call (e.g., the designatedcaller) manually records the confirmation. For example, the user recordssome or all of the confirmation by writing it down, printing it outand/or storing it in memory.

In step 130, the assigned user initiates the connection process. Theuser typically does so by contacting controller unit 24 using a voiceenabled device 26, 28 (e.g., via a voice interface) or using an Internetenabled device 14, 16 (e.g., via entries in a Web page).

In step 132, the assigned user is prompted to enter the reference codeapplicable to the transaction. In step 134, the controller unit 24receives the reference code so input by the assigned user and retrievesthe connection instruction 34 associated with that reference code. In anexample case, the controller unit 24 retrieves that connectioninstruction 34 from connection instruction database 102.

In step 136, controller unit 24 tests whether connection criteria of theconnection instruction are satisfied. This testing preferably includesverification of the initiating user's identity and agreement with theconnection's scheduled time. If the connection criteria are not met, theconnection is rejected, in step 138. Following such rejection, theservice/system may be implemented to provide, as a step 139, notice tothe called party of the rejected connection. Such notice, if implementedat all, may comprise the identity of the initiating user (or, at least,of the proper initiating user), details of the scheduledtransaction/connection, and the basis for rejecting the connection.

If the connection criteria are satisfied, the process proceeds to step144 wherein the controller unit 24 routes the call to the called party.

Alternatively to step 126, the confirmation may be stored automatically(i.e., without the user's action). Such storage typically is providedusing a hardware, firmware and/or software (collectively, the“connection program”).

The connection program preferably is implemented not only toautomatically store the confirmation, but also to automatically retrieveall or part of the confirmation. In so retrieving, the connectionprogram preferably either/both reminds the user of the connection (step140) and/or obtains the user's authorization to automatically initiatethe connection at the scheduled time, including by providing thereference code (step 142). Steps 140 and 142, in an example case, may beimplemented in a device that is both packet-and voice-enabled, e.g., anInternet-enabled cellular phone (hereafter referred to as a“dual-enabled device”).

It is to be recognized that, in a fully automated system, step 140 maybe selectable (e.g., by the user) or may be omitted. If selectable, step140 may be made variously configurable. For example, the user may beenabled to configure the connection program to provide one or morereminders of the scheduled connection time. The user may also be enabledto determine whether to proceed with connection. FIG. 5 depicts anexample of a reminder as a user interface screen, which the connectionprogram may cause to be presented on a dual-enabled device's display.

The service/system may also be implemented to support dual modes: onemode providing for manual reception and treatment of confirmations andanother mode providing for automatic connections. In thisimplementation, if a user requests immediate connection in a transactionspecification 32 (i.e., in step 112), the connection program immediatelyprocesses the connection, doing so automatically and in real time. Thisimplementation provides that later scheduled (not immediate connection)transactions may proceed manually. In that alternative, thisimplementation may provide that a user may select manual or automatic,or both (e.g., automatic confirmation reception and reminders, butmanual connection initiation), such as on a transaction by transactionbase. FIG. 6 depicts an example of a user interface screen, which theconnection program may cause to be presented on a dual-enabled device'sdisplay.

In step 144, controller unit 24 routes the call to the called party. Theunit 24 preferably is enabled to do so via contact information providedin the associated connection instruction(s) and stored in the connectioninstruction database 102.

In step 146, the service/system tests whether a connection isestablished. If the called party cannot be contacted in accordance withthe connection instructions, controller unit 24 may be implemented toprovide further assistance, as step 148. In one example of furtherassistance, the unit 24 requests that the caller call again. Thecontroller unit 24 may do so with a suggested time (e.g., based oninformation about the called party's schedule, whether maintained instorage or obtained at the time of the connection). The controller unit24 preferably also notifies the called party, e.g., of the attemptedconnection and/or of the suggested time for the later call.

With connection established between the parties, the controller unit 24preferably generates transaction logs, as step 150. Information beinglogged may include, as examples in step 152, the identity ofcommunicating parties, billing information, reference codes (e.g., forthe purpose of identifying the transaction), connection time,conversation duration, and satisfaction rating of each party. The logspreferably are stored in communication records database 104.

In step 154, connection reports are transmitted to servers 20, 22. Atleast some reports preferably are formulated based on the transactionlogs. The servers 20, 22 (e.g., Web servers) employ the reports for,among other purposes, billing and record keeping.

As previously described, FIG. 5 depicts an example of a reminder as auser interface screen 170 in connection with step 140 of FIG. 4B. Theuser interface screen 170 can be presented on displays such as, asexamples, of personal computers, Internet appliances, Internet-enabledPDAs and/or digital cellular phones. The screen 170 preferably includesinformation including, but not limited to, the identity 172 of thecalled party, the scheduled time for the transaction 174 and the currenttime 176. The screen 170 preferably also includes virtual buttons 178,180 that are selectable (e.g., by tapping on them if the display istouch sensitive, or by clicking on them using a pointing device, such asa mouse, or by using corresponding keys on a keypad/keyboard).

As previously described, FIG. 6 depicts an example of a user interfacescreen 190 for an automatic connection feature associated with step 142of FIG. 4B. In particular, the screen 190, as depicted, enables atransacting party to initiate an immediate connection (i.e., byselecting the “now” button 192). The screen 190, as depicted, alsoenables a transacting party to terminate the connection process (e.g.,by selecting the “cancel” button 194).

Accordingly, the subject matter of this application is directed toprivacy concerns through the establishment, maintenance and control ofanonymity in the context of voice communication. To illustrate, thesubject matter is directed to establishing, maintaining and controllinganonymity on the part of users and experts alike in information markets,particularly information markets involving the Internet.

In another aspect, the subject matter of this application is directed,in one aspect, to integrating voice communication and anonymity. Thatis, the subject matter is directed to enabling parties involved in anonline transaction to communicate by voice while selectively preservinganonymity; e.g. each party can select what, if any, personal informationis disclosed to the other.

In yet another aspect, the subject matter of this application isdirected to establishing and controlling anonymity at the time ofnon-voice communication involving the Internet, then controlling andmaintaining that anonymity for voice communication, whether thatcommunication is transmitted via the Internet or other packet-switchedtechnologies or that communication is transmitted via circuit switchedtechnologies and services, such as PSTN/POTS.

The foregoing embodiments and features are for illustrative purposes andare not intended to be limiting persons skilled in the art capable ofappreciating other embodiments from the scope and spirit of theforegoing teachings.

It will be appreciated that the invention is not restricted to theparticular embodiment that has been described, and that variations maybe made therein without departing from the scope of the invention asdefined in the appended claims and equivalents thereof. Unless thecontext indicates otherwise, a reference in a claim to the number ofinstances of an element, be it a reference to one instance or more thanone instance, requires at least the stated number of instances of theelement but is not intended to exclude from the scope of the claim astructure or method having more instances of that element than stated.

1. A method of facilitating anonymous communication between a first station and a second station, the second station having an address for communication, and each station being enabled to transmit and receive packet data and being connected directly to a packet data network, the method comprising: providing a transaction specification from at least one of the first and second stations, generating a reference code in response to the transaction specification, there being a defined relationship between the reference code and said address, supplying the reference code to at least the first station, receiving a communication request from the first station, receiving the reference code from the first station, using the reference code to recover said address, and opening a channel for communication between said first and second stations, whereby anonymous communication can be established between the first and second stations without providing said address to the first station.
 2. A method according to claim 1, wherein said address specifies a node on a circuit switched network.
 3. A method according to claim 1, wherein said address specifies a node on a packet switched network.
 4. A method according to claim 1, wherein said address specifies a node on a packet switched network, including Voice over IP.
 5. A method according to claim 1, wherein the step of providing the transaction specification includes inputting said transaction specification through a packet data network.
 6. A method according to claim 1, wherein there is a first party at the first station and a second party at the second station, and the step of providing the transaction specification includes the first party posting an inquiry, the second party posting a response, and the first party accepting or rejection the response.
 7. A method according to claim 1, wherein the step of providing the transaction specification includes providing an interface that allows negotiation between parties at the first and second stations respectively regarding the transaction specification.
 8. A method according to claim 1, wherein the step of providing the transaction specification includes inputting said transaction specification through a packet data network, including one of wired or wireless Internet.
 9. A method according to claim 1, comprising generating a connection instruction based on the transaction specification.
 10. A method according to claim 1, comprising generating the reference code based on a connection instruction.
 11. A method according to claim 1, including storing a database of user profiles including said address.
 12. A method according to claim 1, including supplying the reference code to the first station over a packet data network.
 13. A method according to claim 1, including supplying the reference code to the first station over a circuit switched network.
 14. A method according to claim 1, comprising storing the reference code until after the transaction has been completed and then erasing the reference code.
 15. A method according to claim 1, comprising supplying the reference code to both the first station and the second station.
 16. A method according to claim 1, comprising connecting the first station and second station for voice communication over a circuit switched network.
 17. A method according to claim 1, comprising connecting the first station and second station for voice communication over a packet data network.
 18. A method according to claim 1, comprising connecting the first station and second station for voice communication through voice over IP.
 19. A method according to claim 1, comprising verifying the communication request against at least one criterion specified in the transaction specification before opening the channel for communication.
 20. A method according to claim 1, comprising rejecting the communication request if at least one criterion specified in the transaction specification is not satisfied.
 21. A method according to claim 1, wherein there is a party at the second station and the method comprises verifying the identity of the party at the second station before opening the channel for communication.
 22. A method according to claim 1, wherein the method comprises generating a communication record including data regarding the transaction, including at least one of start time, end time, reference code, duration of communication, fee information, and billing information.
 23. A method according to claim 22, wherein first and second identities are associated with the first and second stations respectively and the communication record includes at least one of the first identity and the second identity.
 24. A method according to claim 1, comprising issuing a prompt to the first station to enter the reference code.
 25. A method according to claim 1, wherein there is a first party at the first station and a second party at the second station, the first party is a purchaser of information and the second party is a seller of information, and the method comprises negotiating the transaction specification.
 26. A method according to claim 1, wherein there is a first party at the first station and the method includes the first party initiating a request for communication.
 27. A method according to claim 1, wherein the step of supplying the transaction specification includes specifying a time or time interval for the communication request and the method includes determining whether the communication request is received from the first station at the specified time or time interval.
 28. A method according to claim 1, wherein the step of opening a communication channel includes attempting to establish a connection between the first and second stations, testing whether a connection is established, and, if not, scheduling a time for another attempt.
 29. A method according to claim 1, wherein the method comprises receiving from the second station specified times or time intervals at which a party is available at the second station for communication.
 30. A method of establishing anonymous communication between a first station and a second station, the second station having an address for communication, and each station being enabled to transmit and receive packet data and being connected directly to a packet data network, the method comprising: supplying a transaction specification as packet data over the packet data network from at least one of the first and second stations to a controller, generating a reference code in response to the transaction specification at the controller, there being a defined relationship between the reference code and said address, supplying the reference code from the controller to at least the first station, making a communication request from the first station to the controller, supplying the reference code from the first station to the controller, using the controller to recover said address from the reference code, and opening a channel for communication between said first and second stations.
 31. A method according to claim 30, wherein the method comprises making the communication request automatically by the first station contacting the controller unit.
 32. A method according to claim 30, wherein there is a first party at the first station, and the method comprises making the communication request by the first party contacting the controller.
 33. An apparatus for facilitating anonymous communication between a first party and a second party employing first and second stations respectively, each station being enabled to transmit and receive packet data and being connected directly to a packet data network, the second party having an address for communication, including a means for enabling negotiation of a transaction specification over the packet data network, a means for generating a reference code, there being a defined relationship between the reference code and said address, and for supplying the reference code to at least the first party, a means for receiving a communication request from at least the first party and for receiving the reference code from at least the first party, a means for using the reference code to recover said address, and a means for opening a communication channel between said first party and said address without supplying said address to the first party.
 34. An apparatus according to 33, wherein the means for opening a communication channel includes a means to test whether a connection is established.
 35. An apparatus according to 33, further comprising means to verify the communication request against at least one criterion specified in the transaction specification before opening a communication channel between the first party and said address.
 36. A method according to claim 1, wherein the anonymous communication is voice communication being one of telephone, cellular and voice-over Internet protocol communication.
 37. A method according to claim 1, wherein the anonymous communication is data communication being one of email, chat, messaging and web publishing.
 38. A method of facilitating voice communication between a first station and a second station, the first and second stations being operated by a first party and a second party, respectively, each station being able to transmit and receive packet data and being connected directly to a packet data network, the method comprising: receiving a transaction specification by a controller from at least one of the first and second stations, the transaction specification defining a transaction involving one or more of a product, a service and information, related to the second station or second party, receiving a connection instruction by the controller related to the second station or second party, receiving a communication request by the controller from the first station for voice communication with the second station, providing a reference code by the controller to the first station in response to the communication request, there being a defined relationship between the reference code and the connection instruction, receiving a request for voice communication by the controller from the first station employing at least in part the reference code, the reference code having been previously provided by the controller to the first station, and opening a channel for voice communication by the controller between the first and second stations, the channel for voice communication including voice over Internet protocol and including at least the packet data network that is connected directly to the first station.
 39. A method according to claim 38, in which the reference code includes one or more of an image, graphics, and video, individually or in any combination.
 40. A method according to claim 38, in which the first party is a buyer of the product, service or information, individually or in any combination, and the second party is a seller of the product, service or information, individually or in any combination, the method further comprising charging by the controller at least one of the first and second parties a fee for opening the channel for voice communication.
 41. A method according to claim 38, further comprising posting by the controller over the Internet at least part of the information related to the one or more product, service and information, individually or in any combination, related to the second station or second party.
 42. A method according to claim 38, further comprising sending by the controller the transaction specification over the packet data network sequentially to the first station and to the second station during negotiation of the transaction specification.
 43. A method according to claim 38, in which the reference code includes the connection instruction or a reference to the connection instruction.
 44. A method of facilitating communication between a first station and a second station, the first and second stations being operated by a first party and a second party, respectively, at least the first station having an interface screen device, each station being able to transmit and receive packet data and being connected directly to a packet data network, the method comprising: receiving a transaction specification by a controller from at least one of the first and second stations, the transaction specification defining a transaction involving one or more of a product, a service and information, related to the second station or second party, receiving a connection instruction by the controller related to the second station or second party, the connection instruction including an address or security information, posting by the controller over the Internet information related to the second station or second party, receiving a communication request by the controller from the first station for communication with the second station, providing a reference code by the controller to the first station in response to the communication request, there being a defined relationship between the reference code and the connection instruction, the reference code including one or both of an image and graphics for display on the interface screen of the first station, receiving a request for communication by the controller from the first station employing at least in part the reference code, the reference code having been previously provided by the controller to the first station, and opening a communication channel by the controller between the first and second stations providing communication channel between the first and second stations without requiring said connection instruction or address or security information related to the second party or second station to be provided to the first party, the communication channel including the packet data network that is connected directly to at least one of the first and second stations.
 45. A method according to claim 44, in which the communication includes one or more of voice, chat, messaging, video, web publishing and e-mail, individually or in any combination.
 46. A method according to claim 44, in which the communication includes voice and or video, and the communication channel includes voice over Internet protocol.
 47. A method according to claim 44, in which the first party is a buyer of the product, service or information, individually or in any combination, and the second party is a seller of the product, service or information, individually or in any combination, the method further comprising charging by the controller at least one of the first and second party a fee for communication.
 48. A method according to claim 44, further comprising sending by the controller the transaction specification over the packet data network sequentially to the first and second stations during negotiation of the transaction specification.
 49. A method according to claim 44, in which posting over the Internet information related to the second station or second party, includes posting on a web page one or more of a product, a service and information, individually or in any combination.
 50. A method according to claim 44, in which posting over the Internet information related to the second station or second party, includes posting a curriculum associated with the first party.
 51. A method according to claim 44, in which receiving a transaction specification, includes receiving a transaction specification specifying parameters of a transaction involving voice communication between the first and second stations, the parameters specifying a future designated time for the transaction.
 52. A method of facilitating, voice communication between a first station and plurality of second stations, each station being enabled to transmit and receive packet data and being connected directly to a packet data network, with a party operating each station, the method comprising: receiving a transaction specification by a controller from a plurality of second stations, the transaction specification for each of the plurality of second stations defining a transaction involving one or more of a product, a service and information, related to the associated second station or second party providing the transaction specification, receiving a connection instruction by the controller from each of the associated second stations or second parties, each connection instruction including an address or security information related to the associated second station or second party, posting on a web page over the Internet by the controller information related to the transaction specification of each of the second stations or second parties, receiving a communication request by the controller from the first party for communication with a selected second station or second party among the plural second stations or second parties, providing a reference code by the controller to the first station in response to the communication request, there being a defined relationship between the reference code and the connection instruction of the selected second station or party, receiving a request for voice communication by the controller from the first station employing at least in part the reference code, the reference code having been previously provided by the controller to the first station, and opening a channel of voice communication by the controller that includes voice over Internet protocol between the first and second stations providing communication between the first and second stations without requiring said address or security information related to the second party or second station to be provided to the first party, the communication channel including the packet data network that is connected directly to at least one of the first and second stations.
 53. A method according to claim 52, in which the reference code includes an image and/or graphics.
 54. A method according to claim 52, in which the first party is a buyer of the product, service or information, individually or in any combination, and the selected second party is a seller of product, service or information, individually or in any combination, the method further comprising charging at least one of the first and second parties a fee for opening the channel of voice communication.
 55. A method according to claim 52, in which the communication further includes one or more of chat, messaging, video, web publishing and e-mail, individually or in any combination.
 56. A method according to claim 52, further comprising sending by the controller the transaction specification over the packet data network .sequentially to the first and second stations during negotiation of the transaction specification.
 57. A method according to claim 52, in which receiving a transaction specification, includes receiving a transaction specification specifying parameters of a transaction involving voice communication between the first and second stations, the parameters specifying a future designated time for the transaction. 